home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Chip 1996 April
/
CHIP 1996 aprilis (CD06).zip
/
CHIP_CD06.ISO
/
hypertxt.arj
/
92
/
PDS.CD
< prev
next >
Wrap
Text File
|
1995-09-14
|
28KB
|
507 lines
@VJobb késôn mint soha@N
@VMicrosoft C/C++ PDS 7.0@N
A konkurenciánál jó másfél évvel késôbb, most a
Microsoft is kínál fejlesztôi csomagot a C++-ban programozók
számára. Kíváncsiak voltunk, hogy megérte-e várakozni.
A Microsoft cég C PDS-e mindig is a professzionális
szoftverfejlesztôk legkedveltebb segédeszközei közé
tartozott. Tavaly azonban a konkurencia alaposan
megszorongatta a Microsoft termékét: míg a Microsoft
megmaradt a klasszikus C compilernél, addig a többi gyártó,
például a Borland és a Zortech már régen az
objektumorientált C++-technológiát kínálták. A C/C++ PDS
7.0-val most a Microsoft is belépett az objektumok világába.
A compiler front-end kibôvítése C-rôl C++-ra nem az
egyetlen újítás a C/C++ PDS 7.0-ban. A debuggertôl a
workbenchig szinte mindent továbbfejlesztettek. Ezenkívül az
új rendszerbe beépítették a Windows számára készült eddigi
Software Development Kit-et (SDK) és a Windows 3.1-hez
készült Application Program Interface-t (API).
A Microsoft szemmel láthatóan sok munkát fektetett a
C/C++ PDS-be. Az új rendszer szuperlatívuszok egész sorát
vonultatja fel:
-- több mint száz fejlesztô dolgozott az elkészítésén;
-- a rendszer tömörített formában tizenegy floppylemezt
foglal el. A teljes telepítéshez (beleértve a súgószövegeket
és a példaprogramokat) kis híján 30 Mbyte-ra van szükség a
merevlemezen. A több mint ötezer oldalas dokumentáció jó
tizenkét kilogrammot nyom;
-- a compiler csak 386SX vagy efeletti processzorú
gépeken futtatható. Aki a C/C++ PDS-sel szeretne dolgozni,
annak legalább egy 4 Mbyte memóriájú 386SX géppel és egy 80
Mbyte-os merevlemezzel kell rendelkeznie. Míg a programot
lehetséges ugyan (de nem túl bölcs dolog) kisebb
merevlemezen (40-80 Mbyte) használni, addig a 386-os vagy
486-os CPU nem takarítható meg. Ennek oka a 32 bites
compiler, amely 16 bites gépeken már nem futtatható. A
286-osok, mint fejlesztôi gépek ezáltal végérvényesen
elvesztették szerepüket.
Az eddigi C PDS-sel ellentétben a C/C++ PDS két telepítô
programmal rendelkezik. Az elsô lényegében megfelel annak,
amit a fejlesztôk a 6.0-os rendszerbôl ismernek: DOS alatti
telepítés -- funkcionális, de nem túl kényelmes. îgy azonban
csak egy tiszta DOS-környezetet lehet kiépíteni a compiler
számára.
A teljes rendszer merevlemezre viteléhez szükség van a
második, a Windows által támogatott telepítô programra,
amely kényelmesebb, mint a DOS-változat. Aki ismeri az új
Quick C for Windows-t, annak bizonyára ismerôsnek tûnik a
telepítés. A két telepítô segédeszköz megegyezik a lényeges
pontokban. A telepítô program Windows-változatával is
létrehozható egy tiszta DOS-változat. Ha a merevlemez
kapacitása lehetôvé teszi, akkor azonban ajánlatos a
rendszert mind DOS-, mind Windows-változatban kiépíteni.
@VTelepítési segítség kezdôk számára@N
A rendszer egy párbeszéddobozban konfigurálható.
Választani lehet négy különbözô memóriamodell, négy
célrendszer (DOS, WINDOWS.EXE, WINDOWS.DLL és QUICKWIN) és
három különbözô lebegôpontos könyvtár közül. Ehhez jön még a
példaprogramok, a forrásfile-ok és a DOS grafikai könyvtár
telepítésének lehetôsége. A programozó tehát valóban nagy
kínálatból állíthatja össze saját rendszerét.
A kezdôk rendszerint nem tudnak mit kezdeni az ilyen
nagy kínálattal. Honnan tudnánk, hogy mi mindenre lesz
szükségünk, mielôtt még ismernénk a rendszert. Ezért egy
alapkiépítésû rendszert is telepíthetünk. Ha a PDS-sel való
munka során mégis szükség lenne egyik vagy másik könyvtárra,
akkor az bármikor létrehozható anélkül, hogy ezért a teljes
telepítést elölrôl kellene kezdeni.
A válogatás közben a telepítô program folyamatosan
kiszámítja az összeállított rendszer méretét, s jelzi a
célmeghajtón szabadon maradó terület méretét is.
A telepítô program kihasználja a Windows multitasking
lehetôségeit. Mialatt a másolás és kicsomagolás folyik, a
türelmetlen fejlesztô már belekóstolhat a ""readme"
file-okba. A floppyk cseréje sem vonja el a figyelmét, mivel
azokat csak egyszer kell behelyezni sorban egymás után. A
Microsoft végre figyelembe vette a Winword telepítését ért
kritikákat.
A rendszer telepítéséhez 15--30 Mbyte szabad hely kell a
merevlemezen. Ennek oroszlánrészét a könyvtárak használják
fel. Teljes telepítéskor pusztán ezek 14 Mbyte-ot foglalnak
el. Ehhez jön a header file-ok 1 Mbyte-ja. A compiler és a
segédeszközök további 8 Mbyte-ot foglalnak el. A
súgórendszerhez jó 4 Mbyte-ra van szükség. Aki példákat és
forrásszövegeket is telepít (ami ajánlatos), annak még bô 2
Mbyte-ot kell feláldoznia.
A teljes fejlesztôi rendszer központja, akár az elôzô
változatban, a ""Programmer's Workbench" (PWB -- programozói
munkapad). A PWB ezúttal is tiszta DOS-alkalmazás. Windows
alatt csak a DOS-boxban használható. Sok fejlesztô vágyát,
hogy a C/C++ compiler valódi Windows-környezetben legyen, a
Microsoft még az idén be akarja teljesíteni. A 3.1-es
Windows-változattal így lehetôség lesz a Programmer's
Workbench Windows-ablakon belüli futtatására anélkül, hogy
le kellene mondani az egérrôl. Addig sajnos csak
alternatívák vannak: PWB ablakban vagy PWB egérhasználattal.
Az eddigi PWB (1.10 verzió) lényeges ismertetôjele volt
a szinte már közmondásos komótossága (DOS alatti)
programváltás esetén.
@VFejlesztési ciklus egy másodperc alatt@N
Programozói körökben ezért rosszallóan ""Programmer's
Waitbench"-nek is nevezték. A fô probléma a programok
tesztelése és a hibakeresés volt. A régi verzióval még egy
486-oson is néhány másodpercig tart egy program elindítása a
Workbench-bôl. Még több idô telik el, mire a Workbench a
program lefutása után újra munkára készen áll.
Ebben a vonatkozásban történt egy s más az új PWB-ben. A
teljes ciklus lefutása (indítás-visszatérés) egy gyors gépen
már csak egy szûk másodpercet igényel. îgy most tényleg
hatékonyan lehet dolgozni, ami jó, mivel a hosszú ciklusidôk
miatt a legtöbb fejlesztô egyáltalán nem használta a régi
Workbench-et. A PWB lehetôségei így kihasználatlanul
maradtak.
A Workbench-be be van építve a Microsoft
forrásböngészôje (Source Browser). A böngészôk tágabb
értelemben CASE (Computer Aided Software Engineering)
segédeszközök. A kódgeneráló CASE eszközökkel, mint például
a Quick C for Windows-ból való Quick Case W-vel
összehasonlítva a böngészôket más célra szánták. Nem a
forrásszövegek elkészítésére, hanem azok elemzésére
szolgálnak. E segédeszközöket évekig szinte csak Smalltalk
környezetekben használták.
A Microsoft C programozói már a PDS 6.0-os verziója óta
ismerik a Browsert. A C++ világába való belépéssel
lényegesen megnôtt a Browser jelentôsége.
@VTovábbfejlesztett editor@N
Mivel a böngészôket éppen a terjedelmes
osztálykönyvtárak esetén érdemes használni, ezért jelentôsen
tovább kellett fejleszteni a régi, függvényorientált C
Browsert. Az új Browser már nemcsak függvényhívásokat tud
elemezni, hanem osztályhierarchiákat is.
Már PWB 1.10-nek is egyik nagy erôssége volt a
bôvíthetôség. A hagyományos editorokkal ellentétben, amelyek
csak makrók segítségével bôvíthetôk, a PWB-t C függvények
használatával is hozzá lehet szabni az egyéni igényekhez. E
C függvények nem a megszokott startup kódokat tartalmazzák.
Indításkor ehelyett a PWB tölti be és inicializálja ôket.
A PWB legtöbb belsô funkcióját a C bôvítésekbôl is meg
lehet hívni. Ez nagymértékû rugalmasságot enged meg, aminek
azonban megvan az ára: aki teljesen ki akarja meríteni a
Workbench eme lehetôségét, annak néhány órát rá kell szánnia
a kézikönyv tanulmányozására.
A PWB C függvényekkel való kibôvítésének lehetôsége
elsôsorban azokat a professzionális fejlesztôket célozza
meg, akik nap mint nap használják a Workbench-et. A
hobby-programozók számára vélhetôen elegendôk a makrók. A
már teljesen beépített funkciókon kívül ugyanis még
nagyszámú makro áll rendelkezésre, amelyeket a
felhasználónak már csak a kívánt billentyûhöz kell
kapcsolnia. Az 1.10-es verzióhoz képest további újítás
lelhetô fel a környezeti változóknál. Most mindegyiket a
Workbench-bôl lehet létrehozni és manipulálni. Ezáltal
feloldódik a LIB, az INCLUDE és a HELP korlátozott köre.
Sajnos a megváltozott rendszerkörnyezet nem tárolódik
automatikusan a projekt-adatoknál.
A Workbench megjelenô képe összességében kellemesebb
lett. A legfontosabb újítás ezen a területen az egymást
átfedô ablakok. A Workbench ebben végre elérte a kornak
megfelelô szintet. Az ablakok száma fölöttébb nagyvonalú
módon maximálisan 16 lehet.
Aki a C compiler 6.0-os verziójából és az SDK-ból álló
kombinációval Windows-programok tesztelését és hibakeresését
akarta elvégezni, annak lényegében egy dologra volt
szüksége: türelemre. A C PDS 6.0 Workbench-e ráadásul nem
képes Windows-programokat elindítani. Ezért a
Windows-fejlesztôknek kerülô úton, mindig a Windows File
Manager-éhez kellett fordulniuk. A Windows-alkalmazások
tesztelése elég idegölô volt.
A probléma kiküszöbölésére a C/C++ PDS 7.0 tartalmaz egy
kis segédeszközt, amelynek neve WX-szerver. A WX-szerver a
Windows alatt indítható, és azt figyeli, hogy valamelyik
DOS-boxban történik-e kísérlet Windows-program indítására.
Ha igen, akkor a WX-szerver közbelép, és elindítja a
programot. E megoldással most már a Windows-programok
(különösképpen a Codeview for Windows) közvetlenül a PWB-bôl
indíthatók. Ezáltal a PWB valamelyest közelebb került egy
Windows fejlesztôi környezet funkcionális lehetôségeihez.
A C/C++ rendszer két compilerbôl áll, egy a C, egy pedig
a C++ programok számára. Mindkét compiler ugyanazt a
kódgenerátort használja. Az új compilerek 32 bites
flat-model programok, ami magával von néhány következményt:
-- a gazdagép teljes memóriája a compilerek
rendelkezésére áll. Sok olyan korlátozás, ami megnehezítette
a C 6.0A compilerrel végzett munkát, így megszûnt, vagy más
területekre tolódott el. Ez elsôsorban a globális optimáló
számára jelent elônyt, amelynek eddig mintegy száz sor
hosszúságú függvények esetén be kellett vonnia vitorláit. A
32 bites compiler több mint ezer soros függvényeket is
könnyen optimál;
-- a 32 bites flat-model programok futtatásához szükség
van egy DPMI-szerverre (DPMI = DOS Protected Mode
Interface). E feladatot vagy a Windows látja el, hiszen van
saját, beépített DPMI-szervere, vagy a mellékelten
szállított 386Max DPMI-szerver. Azonban a védett módú
szolgáltatások is a CPU idejét foglalják le, tehát a DPMI
használatakor kissé csökken a teljesítmény. Cserébe a 32
bites utasítások olyan hatalmas elônyöket adnak, hogy a 32
bites flat memóriamodellre való átállás kétségtelenül a
helyes irányba mutat.
@VMost még jobb az optimálás@N
A kódgenerátor mindig is a Microsoft C compilerek
erôssége volt. E hagyományhoz méltó az új verzió
kódgenerátora is. Az MSC 6.0A compilerhez képest a lényeges
továbbfejlesztések az automatikus vagy explicit inlining és
a globális optimálás területén történtek.
Az explicit inlining technikát már tervbe vették a C++
nyelvi szabványában. Az inline-nak nevezett függvényeket
minden meghívásnál közvetlenül a kódba ültetik. îgy az
egyébként szükséges belépési és kilépési kódrészek
feleslegessé válnak.
Kisebb függvények esetén elôfordulhat, hogy ezek a kódok
teszik ki a végrehajtáshoz szükséges idô nagyobbik részét.
Az inline függvények tehát bizonyos mértékig a makróknak
felelnek meg. Mivel a makrók kockázatosak, ezért az explicit
inlining technika komoly továbbfejlesztés.
Egy lépéssel elôrébb van az automatikus inlining.
Ilyenkor a compiler maga dönti el, hogy közvetlenül a kódot
használja fel, vagy meghívja a függvényt.
Még mélyebbre ható optimálások teszik lehetôvé a
compiler számára, hogy minél tökéletesebb kódokat állítson
elô. A C 6.0A compilere mindig csak egyes függvényeket
tudott optimálni. E határok most kitolódtak.
Azonban nem szabad azt elfelejtenünk, hogy már a C 6.0A
compiler is igen magas szintû volt. Már a C 6.0A is alaposan
kiütötte a nyeregbôl a konkurens Borlandot és Zortechet, és
a Watcom compiler sem tudott lényeges elônyöket elérni.
Erôsen a lefordított programtól függ, hogy az új optimálások
a gyakorlatban valóban lényegesen megnövelik-e a sebességet.
Sebességre szabott forráskód esetén már a C 6.0A is nagyon
jó kódokat állít elô.
Inkább azok a programok jelentenek problémát a 6.0-os
compiler számára, amelyek intenzíven használják a kis
függvényeket.
@VOptimált benchmark@N
Ilyenkor az új compilernek sokkal jobbak az eredményei.
Lehetôvé teszi a programok megtisztítását anélkül, hogy
csökkenne a teljesítmény.
Különösen a benchmark programokkal bánik agresszíven a
Microsoft compiler. Egyrészt a benchmarkok rendszerint csak
kis függvényeket tartalmaznak. Másrészt sok mûvelet
felesleges, illetve nincs messzeható következménye a program
számára, így a compiler egyáltalán nem állítja elô a
mûveletnek megfelelô kódot.
Különösen kirívó példa a Dhrystone régi, 1.1 verziója. A
C 6.0A egy 25 MHz-es 486DX gépen 20|000 dhrystone-t ér el,
az új compiler pedig a mesébe illô 29|500-at. A gyakorlatban
igen ritka az ilyen nagyságrendû javulás, s ha mégis
megtörténik, akkor a forrásszöveg kifejezetten kis
hatékonyságú volt. Valós programoknál a futási idô
legfeljebb 10--15 százalékkal javul. A kódminôség jobban
látszik az elôállított kód megtekintésekor, mint
benchmarkokon keresztül (lásd a listát).
A Microsoft állítása szerint már több mint öt éve
használja az összes nagy Microsoft program a P-kód
technológiát (lásd kiemelt szövegünket). A Microsoft azonban
csak most bocsájtja e technikát a többi fejlesztô
rendelkezésére. A P-kód használatával komoly tármegtakarítás
érhetô el.
Aki azt remélte, hogy a 7.0 verzió kódgenerátorával a
Microsoft végre a 386-osok speciális parancskészletét (és
természetesen a bôvített regisztereket) is ki fogja
használni, az csalódik. Most is a 286-os kód a
""csúcsérzés". Aki többet szeretne, annak továbbra is a
Watcom vagy a Zortech compilereihez kell fordulnia. Ez a
tény annál inkább meglepô, hiszen a Microsoft compiler maga
is egy 32 bites flat-model program, amely kihasználja a
386-os és 486-os processzorok speciális lehetôségeit.
A professzionális szoftverfejlesztésben nemcsak a
végtermék játszik szerepet. Tekintettel kell lenni a
programozók idôráfordítására, hiszen messze ez a legnagyobb
költségtényezô (legalábbis kisebb szoftverházaknál). A
Workbench mellett ezért a compiler is gyorsabb lett.
Ehhez elsôsorban két dolog járul hozzá. Egyrészt az
elôre lefordított headereket és a típusleíró header
file-okat csak egyszer kell lefordítani. Ezután elôfordított
formában addig használhatók, amíg nem változtatunk rajtuk.
Tapasztalatok szerint viszonylag ritkán változnak meg a
header file-ok az implementációs részekhez képest.
Másrészt rendelkezésre áll egy új gyorsfordítási
lehetôség. Az eddigi @Kquick compile@N (/qc) opció már nincs meg
a C/C++ 7.0-ban, felváltotta a @Kfast compile@N (/f) opció. Az
új opcióval megszûnnek az eddigi eljárás komoly hátrányai:
-- nagy programokat nem lehetett a /qc-vel lefordítani;
-- a /qc nem fogadott el minden programszerkezetet. Mind
a C mind a C++ fordító kielégíti az ANSI szabványokat (a
C++-nál az ANSI 2.1-et). Ezenkívül vannak további
Microsoftra jellemzô bôvítések, amelyeket azonban ki lehet
kapcsolni.
Már a compiler telepítésekor feltûnik, hogy az új C/C++
PDS már nem támogatja az OS/2-t, ezt operációs rendszert nem
szánták sem gazdagép- sem célgép-rendszernek. A Microsoft
ezt azzal indokolja, hogy minden rendelkezésre álló
fejlesztési forrást már befektettek a Windowsba, mivel a
piac ezt igényli. Ráadásul az OS/2 éppen egy áttörési
fázisban van. Az OS/2 1.x verzióinak napjai meg vannak
számlálva, a 2.0 verzió pedig csak nemrég jelent meg. Ami a
jövôt illeti, a Microsoft nem zárja ki az OS/2 támogatásának
lehetôségét, de konkrétan csupán a compiler egy olyan
változatát jelentették be, amely az OS/2 1.x-et
gazdagép-rendszerként használja. Erre nagy szükség van,
mivel sok fejlesztô dolgozik OS/2 1.x alatt.
@VKapcsolat a Windows 3.1-gyel@N
Az OS/2 1.x számára programokat író
szoftverfejlesztôknek tehát továbbra is a C 6.0A-nál kell
maradniuk.
A Microsoft az utolsó pillanatban döntött úgy, hogy a
Windows 3.1 API-t is beilleszti az új rendszerbe. Vélhetôen
azoknak a kritikusoknak akarnak elébe menni, akik már most
is a PDS 7.1 verzióján spekulálnak. îgy a C/C++ PDS 7.0 az
elsô olyan fejlesztôi rendszer, amely támogatja a Windows
3.1-et.
Egy jó fejlesztôi rendszerhez manapság hozzátartoznak a
nagyteljesítményû könyvtárak is. Már a C 6.0A is nyújtott
ilyesmiket DOS szinten. A Windows világában azonban a
Borland utcahosszal vezetett. Az MSC-ben programozóknak még
a Windows SDK-val sem volt többje mint a csupasz Windows
API. A Borland C++ felhasználói ezzel szemben támogatást
kapnak az OWL-tôl, a Borland Object Windows Library-jétôl.
Ez a könyvtár leegyszerûsíti a programozást a Windowsban,
nagyon jól érvényesül az objektum-koncepció.
A Microsoft Foundation Class-okkal és a hozzátartozó
Application Framework Class-okkal (AFX) kevesebb mint
harminc sor megírásával lehet létrehozni egyszerû Windows
programokat. A klasszikus Windows API-val szemben ez óriási
könnyebbséget jelent.
A Codeview hibakeresônél is történt egy s más. A C++
által megkívánt, kötelezô bôvítéseken kívül további
tökéletesítésekre is sor került. A legtöbb fejlesztô számára
a legérdekesebb újítás valószínûleg a Remote Debugging
(távoli hibakeresés) soros vonalon keresztül. îgy megszûnt
az egyik hátrány a Turbo Debuggerhez képest. A hibakeresô
kezelése nagy vonalakban ugyanaz maradt, úgyhogy
valószínûleg sok programozó továbbra is a Turbo Debuggert
használja majd.
@VNagy programokat egyszerû kifejleszteni@N
A C PDS 6.0 szemmel látható gyenge pontja volt az
overlay-kezelés. Például nem volt lehetett adatokat tartani
overlay-kben. A lemezre való kimentésért kizárólag a
programozó felelt.
A modulorientált overlay-koncepció is sok problémát
jelentett a C 6.0A-ban. Az eddigi overlay-managerrel nem
lehetett a nagy programokat kizárólag logikailag
struktúrálni, állandóan figyelni kellett az
overlay-struktúrára.
A problémák megoldására a Microsoft kitalálta a MOVE-t
(Microsoft Overlay Virtual Environment). Ezzel az új
overlay-kezelôvel sokkal kicsiszoltabban lehet overlay-ket
alkalmazni: a kód és az adatok is lehetnek overlay-kben; a
különbözô overlay-kben lévô függvények kölcsönösen
meghívhatják egymást; az overlay-ket egy @Klast recently used@N
algoritmus koordinálja. Rövidebbek az elérési idôk.
@VIntegrálva van a Windows 3.1@N
A Windowsban való programozás számára nem elégséges a
compiler és a könyvtárak. Windows programok írásához a
fejlesztônek további eszközökre van szüksége, például
párbeszéd- és ikon-editorokra.
A C PDS C 6.0A-ból éppúgy hiányoztak ezek az eszközök
mint a Windows header file-ok. Ezek a Windows SDK
alkotórészei voltak. Miután a Microsoft C/C++ PDS 7.0-e
rendelkezésre bocsájtja a Windows interface-eket, ezek a
segédeszközök természetesen már nem hiányozhatnak. A C 7.0
már tartalmazza a Windows 3.1 hibakeresô magját (Debugging
Kernel).
A C/C++ PDS 7.0 körülbelül 1000 márkába kerül. îgy
minimálisra csökkent a távolság a konkurens Borland cégtôl.
A Borland C++ 3.0-nak tehát ki kell majd állnia a közvetlen
összehasonlítást. Aki már rendelkezik egy Microsoft C
PDS-sel, az 300 márkáért átállhat az új verzióra.
Az új PDS jelentôs elôrelépés a régi C 6.0A rendszerhez
képest. A C++ technológia mellett a fejlesztô kap egy
objektumorientált Windows SDK-t is, amit már a Windows 3.1
számára készítettek. A kódgenerátor ismét nagyot lépett
elôre (még akkor is, ha még messze nem tökéletes). A C
compilerek területén a Microsoft vezetô pozíciója ezáltal
továbbra is biztosnak tûnik.
Feltétlenül szükséges volt a Workbench felgyorsítása. Az
új Workbench-csel végre hatékonyan lehet dolgozni. Azonban a
2.0 verzió sem igazán gyors, e területen még mindig a
Borland van elôrébb. A Workbench rugalmassága és
mindenekelôtt a kitûnô Source Browser viszont lényeges
pluszt jelentenek a PWB számára. A rendszert teljessé teszi
a Codeview és az overlay-manager tökéletesítése és a
fordítási sebesség növelése.
Végezetül kijelenthetjük, hogy érdemes volt várakozni. A
Microsoft C/C++ 7.0-val szemben a konkurenciának biztosan
nem lesz könnyû dolga.
@KChristoph Grunwald@N
@VA P-kód tömör@N
A P-kód a magas szintû nyelvek és az assembly nyelv
keveréke. A P-kód compiler magas szintû nyelvbôl állít elô
P-kódot. E keverékkódot azután egy interpreter hajtja végre.
A P-kód ezért gyorsabb mint a szokásos magas szintû nyelvi
interpreter, de sokkal lassabb mint a valódi gépi kód.
A P-kód technikája már viszonylag régóta létezik. Az
elmúlt években azonban feledésbe merült. A P-kód rendszerek
virágkora a hetvenes évek vége, a nyolcvanas évek eleje
volt. Ennek az idôszaknak a legjobban ismert P-kód compilere
az UCSD-Pascal volt. A P-kódot akkoriban elsôsorban a
hordozhatóság növelése érdekében alkalmazták. Minden új CPU
számára pusztán egy P-kód interpretert kellett megírni. Egy
új kódgenerátor megírásához képest ez viszonylag egyszerû
feladat. Ma már nem fontos ez a szempont. Az Intel 80x86-os
sorozattal a PC-világ már binárisan kompatibilis CPU-k
széles spektrumával rendelkezik.
Most egy másik szempont a döntô, nevezetesen a
memóriaigény. A Microsoft P-kód interpreterének mûveletei
igen hatásosak, egyetlen P-kód utasítás gyakran több x86-os
utasítást is helyettesít. A legtöbb P-kód utasítás kizárólag
regiszterben lévô adatokkal dolgozik, így kiesik a címzések
nagyrésze. A P-kód technikával összességében akár 50
százalékos tármegtakarítás is elérhetô. Ez az érték persze
csak nagy programok esetén érvényes, mivel minden P-kód
programnak tartalmaznia kell az interpretert. Maga az
interpreter körülbelül 6 Kbyte-os, a P-kód helyigénye pedig
mintegy fele a natív kódénak. A kisebb programok tehát nem
nyernek a P-kód technikából. Gyors számolással belátható,
hogy a P-kód értelmesen csak a legalább 12 Kbyte kódot
tartalmazó programoknál használható. Ahhoz, hogy az
idôigényes feladatok végrehajthatók legyenek a gyors, x86-os
natív kódban, lehetséges a P-kód és a natív kód keverése.
@VPéldákkal teszteltük az optimálást@N
Egy fejlesztôi segédeszköz minôségét legjobban az
elôállított kódból lehet leolvasni. Emiatt több listát is
készítettünk.
Az 1-es listán egy olyan program látható, amellyel
komoly problémái vannak a C 6.0A compilernek. Nem képes
optimális kódot elôállítani, mivel az összeadás nem a
main()-en belül történik, hanem egy külön függvényben. A
2-es lista a C 6.0A által elôállított kódot mutatja.
Egészen más az új compiler. Tökéletesen optimálta a
programot. Ehhez számos mûvelet járul hozzá:
-- az add() automatikusan inline-olható;
-- a compiler már a fordítás ideje alatt kiszámolja az
összeadás eredményét. Ezáltal feleslegessé válik a helyi
változók elkészítése. A compiler nem is készíti el ôket;
-- az add() függvény paramétereirôl is lemondhat a
compiler, mivel már egyetlen mûvelet sem történik;
-- mivel sem a paraméterekre, sem a lokális változókra
nincs szükség, a compiler lemond a veremkeretrôl (stack
frame) is.
îgy az egész program a printf() meghívására
egyszerûsödik. Ezt már valóban nem lehet tovább optimálni. A
compiler teljes munkát végzett.
Az elsô próba alapján azt a következtetést vonhatnánk
le, hogy a C/C++ 7.0 tökéletesen optimál. Sajnos nem ez a
helyzet. A 4-es listán elôállított kód azt mutatja, hogy már
egy kis átalakítás a programban elegendô ahhoz, hogy az
optimáló kiessen a koncepcióból. Az 1-es és 4-es lista csak
abban különböznek, hogy a 4-es listában a TEST típus
struktúraként van definiálva, míg az 1-es listában @Kint@N volt.
Azonban a struktúra is csak egyetlen @Kint@N típust tartalmaz, a
program jelentése ugyanaz. A 4-es listában az ideális kód
ezért pontosan az lenne, amit a compiler az 1-es listából
generált. Ehelyett sokkal rosszabb minôségû gépi kódú
programot állít elô.
A következô pontok különösen szembetûnnek:
-- minden lokális változó és paraméter a el van
helyezve, noha a compiler az @Ki3@N-at és a @Ktest@N-et sosem
használja;
-- a paraméterek átmásolódnak, noha az inline függvény
éppolyan jól hozzáférhetne a main() lokális változóihoz;
-- az eredmény nincs kiszámolva a fordítási idô alatt.
A compiler azonban ennél a programnál is végrehajtott
néhány optimálást:
-- Az összeadás eredménye az AX regiszterben tárolódik,
mivel a compiler felismeri, hogy a printf() meghívása után
már nem lesz rá szükség;
-- a printf()-bôl való visszatérés után a vermet már nem
takarítja ki, mivel a következô utasításban visszaáll az
elôzô állapot. A compiler ezt észreveszi;
-- az add() függvény inline függvényként mûködik.
A példa azt mutatja, hogy a C/C++ 7.0 kódgenerátora
ugyan szép teljesítményt nyújt, de még messze nem tökéletes.